home *** CD-ROM | disk | FTP | other *** search
/ Scene Storm / Scene Storm - Volume 1.iso / coding / c / vbcc / machines / amiga68k / doc / vbccamiga68k.doc < prev    next >
Encoding:
Text File  |  1995-11-23  |  9.1 KB  |  223 lines
  1. vbcc - C compiler (c) in 1995 by Volker Barthelmann
  2.  
  3.  
  4. INTRODUCTION
  5.  
  6.     vbcc shall be a free portable ANSI compliant C compiler.
  7.     It is clearly split into a machine independant and a machine dependant
  8.     part and supports emulating datatypes of the target machine on any
  9.     other machine so that it is possible to e.g. make a crosscompiler for
  10.     a 64bit machine on a 32bit machine.
  11.     This document only deals with the machine dependant parts of the
  12.     Amiga68k version.
  13.  
  14.  
  15. LEGAL
  16.  
  17.     vbcc is (c) in 1995 by Volker Barthelmann. All code is written by me
  18.     and may be freely redistributed as long as no modifications are made
  19.     and nothing is charged for it.
  20.     Non-commercial usage of vbcc is allowed without any restrictions.
  21.     Commercial usage needs my written consent.
  22.  
  23.     Sending me money, gifts, postcards etc. would of course be very nice
  24.     and may encourage further development of vbcc, but is not legally or
  25.     morally necessary to use vbcc.
  26.  
  27.  
  28. INSTALLATION
  29.  
  30.     Look at vc.doc.
  31.  
  32.  
  33. ADDITIONAL OPTIONS FOR THIS VERSION
  34.  
  35.     -cpu=n      generates code for cpu n (e.g. -cpu=68020), default: 68000
  36.  
  37.     -fpu=n      generates code for fpu n (e.g. -fpu=68881), default: 0
  38.  
  39.     -sd         use small data model
  40.  
  41.     -sc         use small code model
  42.  
  43.     -d2scratch  use d2 as scratch register (for testing with certain
  44.                 C libraries)
  45.  
  46.     -noa4       don't use register a4 (for testing with certain C libraries)
  47.  
  48.  
  49. SOME INTERNALS
  50.  
  51.     The current version generates assembler output for use with the PhxAss
  52.     assembler (c) by Frank Wille. Most peephole optimizations are done by the
  53.     assembler so vbcc only does some that the assembler cannot make.
  54.     The generated executables will probably only work with OS2.0 or higher.
  55.  
  56.     The registers d0, d1, a0, a1, fp0 and fp1  are used as scratch registers
  57.     (i.e. they can be destroyed in function calls), all other registers are
  58.     preserved.
  59.  
  60.     All elementary types up to 4 bytes are returned in register d0 like
  61.     common on the Amiga (although I think pointers should better be returned
  62.     in a0). If compiled for an fpu, floating point values are returned in
  63.     fp0. All other types are returned by passing a pointer to a static
  64.     object in d0 (may have to be changed).
  65.  
  66.     vbcc uses d0-d7 and a0-a6 for temporary results and register variables
  67.     (a4 is used as small data pointer if -sd is used). a5 can be
  68.     used as frame pointer for automatic variables (but this is not necessary -
  69.     they can be accessed through a7, too). At the moment all local
  70.     variables are addressed via (dist,ax), so a function may have only 32k of
  71.     local variables if code for <=68000 is generated.
  72.  
  73.     The elementary data types are represented like:
  74.  
  75.     type        size in bits        alignment in bytes
  76.  
  77.     char                8                       1
  78.     short              16                       2
  79.     int                32                       2
  80.     all pointers       32                       2
  81.     float(fpu)         32                       2       see below
  82.     double(fpu)        64                       2       see below
  83.  
  84.     Although it would be better to have all 32bit+ types aligned to 4 bytes
  85.     I chose 2 bytes to be compatible with the Amiga system structures which
  86.     unfortunately have longwords aligned to 4n+2-addresses.
  87.  
  88.     The amiga68k code generator at the moment only works on systems
  89.     that store floats and doubles in the same way (IEEE) like the Amiga.
  90.  
  91.  
  92. SMALL DATA
  93.  
  94.     vbcc can access static data in two ways. By default all such data will
  95.     be accessed with full 32bit addresses (large data model).
  96.     However there is a second way. You can set up an address register (a4)
  97.     to point into Your data segment and then address data with a 16bit
  98.     offset through this register.
  99.     The advantages of the small data model are that Your program will
  100.     usually be smaller (because the 16bit offsets use less space and no
  101.     relocation information is needed) and faster.
  102.     The disadvantages are that one address register cannot be used by the
  103.     compiler and that You can use it only if all Your static data occupies
  104.     less than 64kb. Also You may not mix object modules and libraries that
  105.     have been compiled with different data models (You can call functions
  106.     compiled with large data model from object files compiled with small
  107.     data model, but not vice versa and only functions can be called that
  108.     way - other data cannot be accessed) and You probably have to use
  109.     PhxLnk then.
  110.  
  111.  
  112. SMALL CODE
  113.  
  114.     If You use the small code model calls to external functions (i.e. from
  115.     libraries or other object files) are done with 16bit offsets over
  116.     the program counter rather than with absolute 32bit addresses.
  117.     The advantage is slightly smaller and faster code.
  118.     The disadvantages are that all the code (including library functions)
  119.     must be small enough and that You may have to use PhxLnk. However
  120.     You can link objects/libraries together if they have been compiled
  121.     with different code models.
  122.  
  123.  
  124. CPUs
  125.  
  126.     At the moment the values of -cpu=n have those effects:
  127.  
  128.     n>=68020:   - 32bit multiplication/division/modulo is done with the
  129.                   mul?.l, div?.l and div?l.l instructions
  130.                 - tst.l ax is used
  131.                 - extb.l dx is used
  132.                 - 16/32bit offsets are used in certain addressing modes
  133.                 - link.l is used
  134.                 - addressing modes with scaling are used
  135.                 - (dx) is used if no address register is available (not yet)
  136.  
  137. FPUs
  138.  
  139.     At the moment the values of -fpu=n have those effects:
  140.  
  141.     n>68000:    - floating point calculations are done using the fpu
  142.     n=68040:
  143.     n=68060:    - instructions that have to be emulated on these fpus
  144.                   will not be used; at the moment this only includes
  145.                   the fintrz instruction
  146.  
  147.  
  148. MATH
  149.  
  150.     Integer math hopefully works without problems on all cpus. Long multiply
  151.     on cpus <68020 uses inline routines. This may increase code size a bit,
  152.     but it should be significantly faster, because function call overhead
  153.     is not necessary and the compiler can use the registers which already
  154.     contain the sources and/or need the result. However if anyone really
  155.     wants an option for using library routines for multiply, this can easily
  156.     be implemented. Long division and modulo is handled by calls to library
  157.     functions. At the moment standard library calls with parameter passing
  158.     via stack are used. This is rather slow, but division takes quite some
  159.     time anyway.
  160.     (mult/div/mod with constant powers of two are replaced by corresponding
  161.      bitwise operations (mod only if the other operand is unsigned), but
  162.      sums of powers of two not yet).
  163.  
  164.     If no FPU is specified floating point math is done using the C=
  165.     math libraries. 32 bit IEEE format is used for float and 64 bit IEEE
  166.     for double. Float return values are passed in d0 and double is passed
  167.     via pointers. This is rather slow, so if You need good floating point
  168.     performance specify an FPU.
  169.  
  170.     Floating point math is done with the FPU if one is specified (see above).
  171.     Floating point values are kept in registers then and therefore may
  172.     have extended precision sometimes, which is not ANSI compliant (but
  173.     will usually cause no harm). When floating point values are stored in
  174.     memory they use the same IEEE formats as without FPU.
  175.     Float or double return values are passed in fp0.
  176.  
  177.     Note that You must not link object files together if they were not
  178.     compiled with the same -fpu settings and that You have to link with
  179.     the proper math library (see vclib.doc).
  180.  
  181.  
  182. OPTIMIZATION
  183.  
  184.     Bit 7 (128)
  185.  
  186.     The intermediate code does not contain any of the 68k addressing modes,
  187.     so if they are to be used an extra pass over the intermediate code is
  188.     necessary to recognize certain patterns that can be expressed using a
  189.     68k addresing mode. When bit 7 (128) is set with the -O=n option (or
  190.     -O2 with vc), vbcc tries to use some 68k addressing modes.
  191.     Currently (ax)+ and subsets of (displ,ax,dy*skal) are used.
  192.     However not all cases where those addressing modes could be used are
  193.     recognized.
  194.     During this pass some other minor optimizations may be done.
  195.     Compile time increases slightly if this optimization is turned on.
  196.  
  197.     Bit 8 (256)
  198.  
  199.     Automatic variables are addressed through a7 instead of a5. This
  200.     generates slightly better code, because the function entry and exit
  201.     overhead is reduced and a5 can be used as register variable etc.
  202.     However this may be a bit confusing when debugging.
  203.     Also arguments of function calls are not always popped immediately
  204.     after the call, so that the arguments of several calls may be popped
  205.     at once.
  206.     This optimization should have no effect on compile time.
  207.  
  208.  
  209. KNOWN PROBLEMS
  210.  
  211.     - Converting between unsigned integers and floating point values is
  212.       not always correct.
  213.  
  214.     - Under certain circumstances incorrect code for comparisons may be
  215.       generated - You should get an internal error then. (should be fixed)
  216.  
  217.  
  218. Volker Barthelmann                                      volker@vb.franken.de
  219. Kennedy-Ring 39
  220. 91301 Forchheim
  221. Germany
  222.  
  223.